Software update method, apparatus and system

ABSTRACT

A system for remotely updating software on at least one electronic device connected to a network. The electronic devices have a non-volatile rewritable storage unit divided into at least two partitions, one of which will contain core firmware and the other of which will contain auxiliary software. When an update is received at the device, the updated core firmware is written to overwrite the partition in the rewritable storage unit that contained the auxiliary software. When this is completed and verified, the previous version of the core firmware stored in the storage unit is disabled from execution by the device. Next, the updated auxiliary software is written to overwrite the old version of the core firmware. When this write is complete, the device determines a suitable time for it to be rebooted to execute the updated software. In another embodiment, the present core firmware in the device is copied from the partition it is in to the other partition, overwriting the auxiliary software stored there. The new core firmware received to update the device is overwritten into the first partition, the old copied core firmware being present in case of an upgrade failure, and upon a successful update of the first partition, the auxiliary software is written to the second partition, overwriting the copied old core firmware. In this manner, the position of the core firmware and auxiliary software within the partitions is preserved during normal operation of the device.

FIELD OF THE INVENTION

The present invention relates generally to a method, apparatus andsystem for updating software in a remotely located electronic device.More specifically, the present invention relates to a method, system andapparatus for updating software in remotely located electronic devicesconnected to a network in which the devices can recover from an updatefailure and complete the update through the network.

BACKGROUND OF THE INVENTION

Many common electronic devices include rewritable memory that allowssoftware or data that persists in the device, when the device ispowered-down, to be changed or replaced. Presently, such rewritablememory is typically flash memory, or equivalents, although other typesof memory or storage can be employed. Flash memory is a type ofsolid-state memory that is nonvolatile, in that it does not lose itsdata when the power is turned off, and yet is rewritable to containdifferent data. Flash memory is popular because it is compact,reasonably durable, fast and re-writable. For example, cellular phonesuse flash memory to hold software implementing telephone features, speeddial numbers, ringing tones, firmware updates, etc. So, as new featuresor bug fixes are implemented, the firmware in the electronic device canbe updated.

However, flash memory or its equivalents are not without disadvantages.One disadvantage is that flash memory is relatively expensive. Indevices for which the manufacturer needs to keep the consumer costs low,the devices must be engineered to minimize the amount of flash memoryrequired.

While the ability to update firmware or other software or data in adeployed device is clearly desirable, updating flash memory in anelectronic device is not always simple. For example, when most cellularphones require a firmware or other software update, the cell phone mustbe taken into a local service center where the software can be updatedby attaching the cell phone through a wired data link to an updatestation holding the updated software. If there is a problem intransferring the new software during the update session, resulting inthe device being placed into an unknown or inoperable state, the devicecan be reset and the new software can simply be transferred again untilthe transfer completes and the device functions properly.

However, this is seldom an attractive option as it requires the activeparticipation or cooperation of the user who must visit the servicecenter. With some devices, such as a wireless local loop subscriberstation, taking the subscriber station into a service center means that,in addition to the inconvenience of the trip to the service center, theresidence at which the subscriber station is normally located istemporarily without telephone or data services.

Prior attempts have been made to provide updates to non-volatilerewritable memory in devices through the network to which they areattached. For example, a cell phone can receive software updates for itsflash memory through the wireless network that services it. However,problems exist with such techniques in that, should the transmissionfail or be corrupted for any reason, the device may be left in anunknown or inoperative state. In such a case, unlike the example aboveat which an update is done at a service center, attempts to resend theupdate software could be impossible and the user would be left with aninoperable device until it was returned to a service center.

One prior solution to this problem has been to provide separate banks ofrewritable memory. U.S. Pat. No. 6,023,620 to Hansson teaches a cellphone system wherein half of a rewritable memory is a bank used tomaintain the current version of the software while the updated softwareis downloaded into a bank that is the other half of the rewritablememory. Once the cell phone determines that the transfer has beensuccessful, e.g., by verifying a CRC, the cell phone switches to usingthe updated bank of memory and the bank containing the old software isavailable to receive the next update. A similar prior art solution istaught in U.S. Pat. No. 6,275,931 to Narayanaswamy et al. Thesearrangements prevent a non-recoverable error from occurring during anupdate, but require twice as much expensive rewritable memory.

Also, the prior art update methods discussed above typically require thecooperation or participation of the user of the device, either requiringthem to visit the service center or requiring them to accept or initiatethe transfer of update data through the network. A crucial update, suchas one that will improve stability or capacity in the network for thenetwork operator, may be refused or otherwise delayed by some users dueto the inconvenience to them. Additionally, with the prior art methodsknown to the inventors, the updating of each device in the network mustbe performed separately.

It is desired to have a method and system of reliably updating softwareor data in non-volatile rewritable memory of devices connected to anetwork which does not require double the amount of non-volatilerewritable memory in the devices and which can be achieved automaticallyand in parallel on multiple devices.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide a novel method,system and apparatus for updating, through a network, software inelectronic devices that obviates or mitigates at least one of theabove-identified disadvantages of the prior art.

According to a first aspect of the present invention, there is provideda system for remotely updating at least one electronic device across acommunications link. The system includes an update server, a volatilememory, a non-volatile rewritable storage unit within said at least oneelectronic device, and an update client executing on the device. Theupdate server is operable to transfer an update, comprising corefirmware and auxiliary software, to the at least one electronic deviceacross the communications link. The volatile memory is used totemporarily store the transfer received from the update server. Thenon-volatile rewritable storage unit is divided into at least first andsecond partitions, the first partition storing one of a version of thecore firmware and auxiliary software and the second of the partitionsstoring the other of a version of core firmware and auxiliary software.The update client executes on the device and is operable: (i) tooverwrite the version of the auxiliary software stored in one of thefirst and second partitions with the received updated core firmwarestored in the volatile memory and to verify the success of this write;(ii) to configure the device to execute the core firmware stored in (i)upon the next reboot of the device; (iii) to overwrite the version ofthe core firmware stored in the other of the first and second partitionwith the received updated auxiliary software store in the volatilememory and to verify the success of this write; and (iv) to reboot thedevice to execute the updated core firmware and updated auxiliarysoftware.

According to another aspect of the present invention, there is provideda method of updating software in a plurality of remote devices connectedto a network. The method includes the steps of: (i) placing an updateonto an update server, the update comprising at least a core firmwareupdate; (ii) identifying the devices connected to the network to beupdated; (iii) transferring the update from the update server to theidentified devices through the network, each identified device verifyingthe reception of the update, requesting retransmission of and receivingany previously incorrectly received portion of the update; (iv) writingand verifying the core firmware portion of the received update into apartitioned non-volatile rewritable storage unit, the core firmwareportion overwriting a partition containing a previously stored versionof software while ensuring that a valid copy of the previous version ofthe core firmware is always present in the storage unit; (v) identifyingthe verified updated core firmware partition as being the valid corefirmware to be used by the device and identifying the previous versionof the core firmware as being unusable; and (vi) rebooting the device toload and execute the updated software.

Optionally, before the core firmware portion of the received update iswritten into the partitioned non-volatile rewritable storage unit, theprevious version of the core firmware may be copied over auxiliarysoftware stored in the storage unit and verified, the copy identified asthe valid core firmware to be used by the device, and then the originalidentified as being unusable.

Also, the update may include updated auxiliary software. The auxiliarysoftware is received and verified by the device and then, before thedevice is rebooted, the unusable previous version of the core firmwareis overwritten with the auxiliary software update.

According to another aspect of the present invention, there is provideda system for remotely updating core firmware in at least one electronicdevice across a communications link. The system includes a memorysub-system within the electronic device and an update server that isoperable to transfer an update, including at least the updated versionof the core firmware, to the electronic device across the communicationslink. The memory sub-system includes non-volatile rewritable memory inwhich the core firmware is stored and which is sufficiently large tostore auxiliary software but not large enough to simultaneously storethe core firmware, an updated version of the core firmware, and theauxiliary software. The core firmware includes instructions for (i)writing an updated version of the core firmware into the non-volatilerewritable memory so as not to overwrite the previous version of thecore firmware and optionally verifying the write, and then (ii)disabling the previous version of the core firmware such that onrebooting of the at least one electronic device the updated version ofthe core firmware will be loaded and executed.

The core firmware may also include instructions for writing an updatedversion of the auxiliary software into the non-volatile rewritablememory so as to overwrite at least a portion of the disabled previousversion of the core firmware, but not to overwrite the updated versionof the core firmware. Optionally the write may be verified.

The memory sub-system may additionally include non-volatile memory inwhich are stored instructions that are executed when the electronicdevice reboots and cause the non-volatile rewritable memory to bescanned for a version of the core firmware that is not disabled. When anon-disabled version of the core firmware is found then that version isloaded and executed.

According to yet another aspect of the present invention, there isprovided a system for remotely updating core firmware and auxiliarysoftware in at least one electronic device across a communications link.The system includes a memory unit within the at least one electronicdevice for storing the core firmware and the auxiliary software and anupdate server that is operable to transfer an update to the at least oneelectronic device across the communications link. The memory unitincludes a non-volatile rewritable memory in which is stored in a firstpartition, a first memory content that includes the core firmware, andin a second partition large enough to store the first memory content, asecond memory content that is small enough to be stored in the firstpartition and that includes the auxiliary software. The core firmwareincludes an update client which, after an updated version of the firstmemory content is received, writes the updated version of the firstmemory content into the second partition overwriting the second memorycontent, optionally verifies the write, and disables the first memorycontent that is contained in first partition, and then after an updatedversion of the second memory content is received, writes the updatedversion of the second memory content into the first partitionoverwriting the disabled first memory content and reboots the electronicdevice. The memory unit also includes non-volatile memory in whichboot-loading instructions are stored that are executed when theelectronic device is rebooted. The boot-loading instructions includeinstructions that when executed search the non-volatile rewritablememory for a version of the first memory content that is not disabledand, when one is found, turn over control of the electronic device tothe core firmware stored in that memory content.

Alternatively, the update client may, after an updated version of thefirst memory content is received, copy the first memory content into thesecond partition overwriting the second memory content, write theupdated version of the first memory content into the first partitionoverwriting the first memory content, optionally verify the write, andthen after an updated version of the second memory content is received,write the updated version of the second memory content into the secondpartition, optionally verify the write, and reboot the electronicdevice.

Also alternatively, the update client may, after an updated version ofthe first memory content is received, reduce the size of the secondpartition so that it is just large enough to store the updated versionof the first memory content, write the updated version of the firstmemory content into the second partition overwriting the previouscontents of the second partition, optionally verify the write, anddisable the version of the first memory content that is stored in firstpartition, and then, after an updated version of the second memorycontent is received, increase the size of the first partition to includeany portion of the non-volatile rewritable memory not in the secondpartition, write the updated version of the second memory content intothe first partition overwriting the previous contents of the firstpartition, optionally verify the write, and reboot the electronicdevice.

Optionally, the update client may be further operable to inform theupdate server as to whether the at least one electronic device isavailable for updating at a given time, the update server beingresponsive to the information received from the update client to delayupdates to the electronic device when the electronic device is notavailable for updating. The update server may also prioritize an updatesuch that the update client will make the electronic device availablefor the update that would otherwise be unavailable.

According to yet another aspect of the present invention, there isprovided a memory sub-system for use in an electronic device thatincludes a non-volatile rewritable memory in which core firmware andauxiliary software are stored. The core firmware includes instructionsfor writing an updated version of the core firmware into thenon-volatile rewritable memory so as to overwrite at least a portion ofthe auxiliary software, but not to overwrite the previous version of thecore firmware, verifying the updated version of the core firmware, anddisabling the previous version of the core firmware such that onrebooting of the electronic device the updated version of the corefirmware will be loaded and executed. The core firmware may includeinstructions for writing an updated version of the auxiliary softwareinto the non-volatile rewritable memory so as to overwrite at least aportion of the disabled previous version of the core firmware, but notto overwrite the updated version of the core firmware. The memorysub-system may also include non-volatile memory storing instructionsthat are executed when the electronic device reboots and cause thenon-volatile rewritable memory to be scanned for a version of the corefirmware that is not disabled and the version of the core firmware thatis not disabled to be loaded and executed.

According to yet another aspect of the present invention, there isprovided a memory sub-system for use in an electronic device thatincludes a non-volatile rewritable memory in which core firmware isstored and which is sufficiently large to store the core firmware andauxiliary software but not large enough to simultaneously store the corefirmware. The core firmware includes instructions for writing an updatedversion of the core firmware into the non-volatile rewritable memory soas not to overwrite the previous version of the core firmware, verifyingthe updated version of the core firmware, and disabling the previousversion of the core firmware such that on rebooting of the electronicdevice the updated version of the core firmware will be loaded andexecuted. The core firmware may include instructions for writing anupdated version of the auxiliary software into the non-volatilerewritable memory so as to overwrite at least a portion of the disabledprevious version of the core firmware, but not to overwrite the updatedversion of the core firmware. The memory sub-system may also includenon-volatile memory storing instructions that are executed when theelectronic device reboots and cause the non-volatile rewritable memoryto be scanned for a version of the core firmware that is not disabledand the version of the core firmware that is not disabled to be loadedand executed.

According to yet another aspect of the present invention, there isprovided for use in an electronic device capable of executing storedinstructions and receiving updated versions of such instructions, amemory sub-system for storing such instructions that includesnon-volatile rewritable memory and non-volatile memory. In thenon-volatile memory boot-loading instructions that are executed when theelectronic device is rebooted are stored. In the non-volatile rewritablememory there is stored in a first partition, a first memory content thatincludes at least instructions necessary to allow the electronic deviceto restart or continue updating the non-volatile rewritable memory ifthe electronic device reboots while an update is in progress and in asecond partition large enough to store the first memory content, asecond memory content that is small enough to be stored in the firstpartition and that includes all instructions not included in the firstmemory content that are needed for the normal operation of theelectronic device after a reboot. The instructions stored in the firstmemory content include instructions which, when executed after anupdated version of the first memory content is received, write theupdated version of the first memory content into the second partitionoverwriting the second memory content, and disable the first memorycontent that is contained in first partition, and instructions which,when executed after an updated version of the second memory content isreceived, write the updated version of the second memory content intothe first partition overwriting the disabled first memory content, andreboot the electronic device.

Alternatively, the instructions stored in the first memory content mayinclude instructions which, when executed after an updated version ofthe first memory content is received, copy the first memory content intothe second partition overwriting the second memory content, write theupdated version of the first memory content into the first partitionoverwriting the first memory content, and instructions which, whenexecuted after an updated version of the second memory content isreceived, write the updated version of the second memory content intothe second partition overwriting the disabled first memory content andreboot the electronic device.

Alternatively, the instructions stored in the first memory content mayinclude instructions which, when executed after an updated version ofthe first memory content is received, reduce if possible the size of thesecond partition so that it is just large enough to store the updatedversion of the first memory content, write the updated version of thefirst memory content into the second partition overwriting the previouscontents of the second partition, and disable the version of the firstmemory content that is stored in first partition, and instructionswhich, when executed after an updated version of the second memorycontent is received, increase if possible the size of the firstpartition to include any portion of the non-volatile rewritable memorynot in the second partition, write the updated version of the secondmemory content into the first partition overwriting the previouscontents of the first partition, and reboot the electronic device.

According to yet another aspect of the present invention, there isprovided a method of installing an update to software stored in anon-volatile rewritable memory that is not large enough to hold both theupdate and the software. The method includes the steps of: dividing theupdate into separately writable portions including a core portion thatcan be stored in not more than half of the non-volatile rewritablememory; dividing the non-volatile rewritable memory into separatelyrewritable portions including a core portion including not more thanhalf of the non-volatile rewritable memory and containing the portion ofthe software corresponding to the core portion of the update and anauxiliary portion just large enough to hold the core portion of theupdate; writing the core portion of the update into the auxiliaryportion of the non-volatile rewritable memory and verifying it;disabling the previous version of the software contained in the coreportion of the non-volatile rewritable memory; and writing the portionof the update not included in the core portion of the update into theportion of the non-volatile rewritable memory not included in the coreportion of the non-volatile rewritable memory and verifying it.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will now be described, by way ofexample only, with reference to the attached Figures, in which:

FIG. 1 is a block diagram of a network permitting upgrading ofelectronic devices in accordance with an embodiment of the invention;

FIG. 2 is a block diagram of an update station, in accordance with anembodiment of the invention;

FIG. 3 is a block diagram of an updateable electronic device, inaccordance with an embodiment of the invention, including a memory unit;

FIGS. 4 a, 4 b and 4 c are block diagrams of the memory unit in theelectronic device of FIG. 3, in accordance with an embodiment of theinvention;

FIGS. 5 a, 5 b and 5 c are block diagrams of memory unit in theelectronic device of FIG. 3, in accordance with another embodiment ofthe present invention;

FIG. 6 is a block diagram of the hierarchy of an update system inaccordance with an embodiment of the invention; and

FIG. 7 is a flowchart of an embodiment of the update process of thepresent invention.

DETAILED DESCRIPTION OF THE INVENTION

Referring now to FIG. 1, a wireless network that enables the upgradingof software or data in at least one electronics device is indicatedgenerally by reference numeral 20. Network 20 includes at least oneupdate station, which in this example is a radio base station 24,operable to transmit software updates across a bi-directionalcommunication link 32. Network 20 also includes at least one electronicdevice, such as subscriber stations 28 a, 28 b, . . . , 28 n for a voiceand data capable wireless local loop. Subscriber stations 28 can be thecustomer premises equipment in a wireless local loop for voice and data,wireless point of sale terminals, or any other electronic devices suchas personal digital assistants (“PDAs”) that have modems, cellularphones, cable modems, laptop computers, and other suitable electronicdevices that will occur to those of skill in the art and that arecapable of communicating through communication link 32.

The number ‘n’ of subscriber stations serviced by a base station 24 canvary depending upon the amount of radio bandwidth available or theconfiguration and requirements of the subscriber stations 28. For thepurposes of clarity, references herein to the electronic device beingupdated will be made only to subscriber stations 28. However, otherelectronic devices such as those that are mentioned above and that areable to receive software updates across a communication link 32 arewithin the scope of the invention.

In network 20, base station 24 can be connected to at least onetelecommunications network, such as a landline-based switched-datanetwork 30, a public-switched telephone network 33 by an appropriategateway and backhauls 34. Backhauls 34 can be links such as T1, T3, E1,E3, OC3 or other suitable landline link, or can be a satellite or otherradio or microwave channel link or any other link suitable for operationas a backhaul as will occur to those of skill in the art. Base station24 can also include, or be connected to by a backhaul 34 or other means,a software update server 36 that contains software loads for subscriberstations 28. Base station 24 is also connected to a subscriber database,located in update server 36 or in a separate database server (not shown)provided for this purpose elsewhere, such as in a centralized networksoperation center (discussed below), which holds records of the currentsoftware loads of subscriber stations 28.

In the wireless network 20, communications link 32 is establishedbetween base station 24 and each subscriber station 28 via radio,although other physical means of connection, including wireline,infrared and ultrasonic means can be employed. Communications link 32can carry voice and data information between base station 24 andrespective subscriber stations 28 a, 28 b . . . 28 n as needed.Communications link 32 can be implemented with a variety of multiplexingtechniques, including TDMA, FDMA, CDMA, OFDM or hybrid systems such asGSM, etc. Furthermore, communications link 32 can be arranged intodifferent channels carrying different data types such as voicecommunications or data transmissions or employed for various purposessuch as end user communications or control of network 20. In theembodiment of FIG. 1, data transmitted over communications link 32 istransmitted as IP (Internet Protocol) packets, but packets of anysuitable type can be employed.

FIG. 2 shows an example of base station 24 in greater detail. Basestation 24 comprises an antenna or antennas 40 for receiving andtransmitting radio-communications over communications link 32. Antenna40 is connected to a radio 44, which in turn is connected to a modem 48.Modem 48 is connected to a microprocessor-router assembly 52 such as aPentium III™ processor system manufactured by Intel and associateddevices. It will be understood that microprocessor-router assembly 52can include multiple microprocessors, as desired. Further, the routerfunctionality of microprocessor-router assembly 52 can be provided in aseparate unit, if desired. The router functionality implemented withinmicroprocessor-router assembly 52 is connected to a backhaul 34 in anysuitable manner to connect base station 24 to at least onetelecommunications network 30, 33. Base station 24 can also be connecteddirectly, or through a backhaul 34, to an update server 36, as mentionedabove.

Referring now to FIG. 3, an example of a subscriber station 28 is shownin greater detail. Subscriber station 28 comprises an antenna orantennas 60, for receiving and transmitting radio-communications overcommunications link 32. Antenna 60 is connected to a radio 64, which inturn is connected to a modem 68. Modem 68 is connected to amicroprocessor-assembly 72, which is connected to a memory unit 78.

Microprocessor-assembly 72 can include, for example, a StrongARMprocessor manufactured by Intel, and performs a variety of functions,including implementing A/D-D/A conversion, filters, encoders, decoders,data compressors, de-compressors and/or packet disassembly. As seen inFIG. 3, microprocessor-assembly 72 also interconnects modem 68 and oneor more ports 76, which may be used to connect subscriber station 28 todata devices and telephony devices. An example of a telephony device isa telephone. Examples of data devices include personal computers, PDAsor the like. Accordingly, microprocessor-assembly 72 is operable toprocess data between ports 76 and modem 68.

In subscriber station 28, memory unit 78 comprises of two principalcomponents: (1) a volatile random access memory (“RAM”) 82, which may bedynamic RAM (DRAM) or synchronous DRAM (SDRAM), used bymicroprocessor-assembly 72 for storing instructions and data requiredfor operating subscriber station 28; and (2) a non-volatile rewritablestorage unit, RSU 86, which in subscriber station 28 is flash memory,used to store data, including instructions, that is not lost whensubscriber station 28 is without power. The memory unit 78 is operableto contain all the necessary instructions and data for the proper anddesired functioning of subscriber station 28, including boot software,operating systems, software applications, radio resource managementsoftware, device drivers, and data files.

As known to those of skill in the art, RAM 82 is typically faster thanthe flash memory used in the RSU 86 and thus, in a presently preferredembodiment of subscriber station 28, instructions and data are in mostcases copied by microprocessor-assembly 72 from the RSU 86 to the RAM 82before execution. In some circumstances, which will be apparent to thoseof skill in the art, instructions or data are read into themicroprocessor-assembly 72 directly from RSU 86 and executed or operatedupon.

Microprocessor-assembly 72 is also operable to write instructions anddata from RAM 82 to RSU 86 as described below.

In subscriber station 28, RAM 82 consists of 32 Mbytes of SDRAM and RSU86 consists of 8 Mbytes of flash memory. However, the quantity and typeof RAM memory is not particularly limited and other types ofnon-volatile rewritable memory, e.g., conventional IDE and SCSI harddrives, optical memory storage devices, and EPROMS may be used insteadof flash memory. Other types of non-volatile rewritable memory willoccur to those of skill in the art, who will also understand themodifications to the following description that may be needed to usesuch alternative non-volatile rewritable memory in RSU 86 in anembodiment of the invention.

Flash memory, such as that used in RSU 86, must typically be read fromand written to in blocks. A block is the smallest unit that can bewritten to and must be erased before it can be written to. (In otherwords, flash memory is “granular” which, as will be discussed below, hasan impact on the way it is used.) Those skilled in the art willunderstand that this constraint does not apply to some other forms ofnon-volatile rewritable memory that could be substituted for flashmemory in subscriber station 28. The particular flash memory presentlyused in subscriber station 28 has a block size of 256 Kbytes. Referringnow to FIG. 4 a, the initial partitioning of the RSU 86 is shownschematically. The RSU 86 is divided into logical partitions, each ofwhich is one or more logically contiguous blocks of storage. As will beapparent to those of skill in the art, the terms “partition” and“logical partition” are used interchangeably herein. The only limitationto the present invention is that, except in the special case in whichpartitions that are equal in size may be used, the partitions shouldre-sizable and/or relocatable. Thus logical partitions and, in somecases, physical partitions that meet this requirement are both intendedto be within the scope of the present invention.

Each partition has at least a start position and a length/size that isdefined for it. As known to those of skill in the art, partitions aretreated for some purposes as if they are separate discrete memorydevices. For example, a hard drive with two partitions may appear toapplication software running on a computer connected to the hard driveas two separate hard drives. Also known to those of skill in the art,logical partitions, and some physical partitions, typically can beadded, removed, or resized in order to provide flexibility within thestorage device. For logical partitions, this is done by modifying a datastructure that is stored in non-volatile rewritable memory or, as is thecase in subscriber station 28, reconstructed on startup, as describedbelow. The data structure contains data, such as the start position andsize/length discussed above, providing a correspondence between physicallocations in the storage device and the logical partitions. Logicalpartitioning can also make non-contiguous storage locations appear ascontiguous blocks of storage to applications. For example, it ispossible to partition a flash ROM such that even numbered blocks(i.e.—blocks 0, 2, 4, 6, etc.) appear to applications as one contiguousblock of storage while the odd-numbered blocks (i.e.—blocks 1, 3, 5, 7,etc.) appear to applications as another contiguous block. Many otherpartitioning schemes and arrangements will be apparent to those of skillin the art and are within the scope of the present invention. Insubscriber station 28, the RSU 86 is initially divided into threepartitions, namely a boot partition 104, a core firmware partition 108and an auxiliary software partition 112.

The boot partition 104 is located in the first block of the RSU 86 andcontains the boot-loading firmware for subscriber station 28. Subscriberstation 28 is configured so that at startup (boot) themicroprocessor-assembly 72 first executes the instructions found in thefirst block of the RSU 86, although other schemes, such as reading thelast block of RSU 86, etc. can also be employed. The remainder of theblocks of the RSU 86 are initially partitioned into a core firmwarepartition 108 and an auxiliary software partition 112 in the mannerdescribed below. In FIG. 4 a, the core firmware partition 108 is shownas occupying the blocks immediately following the boot partition 104 andthe auxiliary software partition 112 is shown as occupying the blocksbetween the last block of the core firmware partition 108 and the end ofthe RSU 86. As will be discussed below, the initial positioning of thecore firmware partition 108 and the auxiliary software partition 112could be reversed and is reversed as a result of an upgrade (see FIG. 4c in which the reversed order is indicated by adding primes to thereference numerals) as discussed below.

In subscriber station 28, the boot-loading firmware is provided in bootpartition 104 to avoid the necessity of providing an additional ROM orother non-volatile storage package in subscriber station 28. However, aswill be apparent to those of skill in the art, if such ROM or othernon-volatile storage package is provided in memory unit 78 or elsewherein subscriber station 28, the boot partition 104 can be placed thereinand omitted from the RSU 86, which would then be arranged into twopartitions 108 and 112. The term “memory sub-system” includes bothmemory unit 78 and, if boot partition 104 is stored in a ROM or anothernon-volatile storage package, that ROM or other non-volatile storagepackage.

The core firmware needed to provide at least minimum functionality tosubscriber station 28 is initially written into core firmware partition108. The core firmware is responsible for providing the basic operationsof subscriber station 28. These basic operations can include memorymanagement, task handling, managing files, input/output, etc. and atleast the minimum amount of functionality required to allow subscriberstation 28 to communicate with the base station 24 (but not necessarilyenough functionality to provide any end user services). In subscriberstation 28, the operating system included in the core firmware includesthe Linux kernel, version 2.4 and the boot-loading software in the bootpartition 104 is a Linux boot loader. The core firmware in partition 108is a cramfs file system, which is a read-only compressed file systemthat is known to those skilled in the art. Documentation of the cramfsfile system is readily available (e.g., seehttp://sourceforge.net/projects/cramfs/) and its operation will not befurther discussed herein.

At start up, once the boot partition has been read and execution of thecontents of the partition commences, the boot loader starts readingsequentially from the start of the RSU 86 to locate the starting blockand size of the core firmware partition 108. The boot loader does thisby looking for a superblock, as defined in the cramfs file system. Whenone is found it is assumed to be the superblock of the compressed Linuxkernel in the core firmware partition 108. The boot loader then uses theinformation stored in that superblock to decompress the kernel imageinto the RAM 82 and passes the starting block and size of the corefirmware partition 108 as boot parameters to the linux kernel as theoperating system starts, so that the partitioning of the RSU can bedetermined.

While Linux is presently preferred, other operating systems andoperating system versions are within the scope of the invention. Thelocation of the core firmware partition 108 within RSU 86 is notparticularly limited and can occupy any contiguous set of logical blockaddresses after the boot partition 104 (if present) as the boot loadersearches the contents of the RSU 86 until the start of a valid corefirmware partition 108, i.e.—a cramfs superblock, is located. However,as should become clear from the following it is preferred that the corefirmware partition 108 be located either immediately after the bootpartition 104 or at the end of the RSU 86 to avoid a situation in whichone or more memory blocks are not in either the core firmware partition108 or the auxiliary software partition 112.

The balance of the software and data are stored in the RSU 86 inauxiliary software partition 112. This software is hereinafter referredto as the auxiliary software. The auxiliary software is not particularlylimited and can include optional device drivers, user applications,system software applications, data files, software and end userapplications such as telephone call processing software, voice and audiocodecs, software filters, firewalls, utilities, help files, subscriberdata files, digital media files, and other such applications and datafiles as will occur to those of skill in the art.

The auxiliary software can be stored in a compressed file system format,such as the above-mentioned cramfs format, or in any other suitablemanner as will occur to those of skill in the art. If the auxiliarysoftware is monolithic, i.e.—changes or updates to the software requirea replacement of the entire contents of the partition, then cramfs, orsimilar file/storage systems can be a preferred alternative.Alternatively, if the auxiliary software is not monolithic, so thatsoftware components can be loaded and/or unloaded in the partition asneed, then a suitable system such as JFFS (Journaling Flash File System)developed by Axis Communications AB, Emdalavägen 14, S-223 69, LundSweden, can be employed.

Generally, the auxiliary software stored in the auxiliary softwarepartition 112 is not required for subscriber station 28 to communicatewith the base station 24, although the auxiliary software stored in theauxiliary software partition 112 may be required to enable subscriberstation 28 to make or receive voice calls, end user data connections(such as http browser sessions) or other end user functions. Thelocation of the auxiliary software partition 112 within RSU 86 is notparticularly limited and need only occupy a logically contiguous set ofblocks but, as discussed above, is preferably either at the end of theblocks of the RSU 86 or immediately following the boot partition 104.

As shown in FIG. 4 a, the core firmware partition 108 is smaller in sizethan the auxiliary software partition 112. However, if the number ofblocks available to be partitioned into the core firmware partition 108and the auxiliary software partition 112 is an even number, then theycan be equal in size. In a present embodiment of subscriber station 28,the total storage space available in the RSU 86 is 8 Mbytes, the bootpartition 104 is 256 Kbytes, the core firmware partition 108 has amaximum size of 3.75 Mbytes, and the auxiliary software partition 112has a maximum size of 7.75 Mbytes minus the size of the core firmwarepartition 108. In the particular embodiment described herein, themaximum size of the auxiliary software block is 4 Mbytes.

As the total number of memory blocks in RSU 86 in the present embodimentis even and as one block is used for the boot partition 104, an oddnumber of blocks are available to be partitioned into the core firmwarepartition 108 and the auxiliary software partition 112 and thus the corefirmware partition 108 and the auxiliary software partition 112 cannotbe equal in size. As will be clear from the following discussion, thecritical constraint is that the core firmware partition 108 must be nolarger than the auxiliary software partition 112. Then an update of thecore firmware can always be written to the auxiliary software partition112 without overwriting the existing core firmware partition 108. Thiswill be more readily apparent after reading the description below.

When it is desired to update the core firmware in the core firmwarepartition 108, the update core firmware is transferred from an updateserver 36, as described in more detail below, over the communicationslink 32 to subscriber station 28. The core firmware is received andstored in the RAM 82 in subscriber station 28 until the entire transferof the update core firmware and the auxiliary software to subscriberstation 28 has been completed, although it is also contemplated that, ifdesired, the update core firmware could be transferred and installedbefore transferring the auxiliary software. Depending upon the size ofthe update and the size of the RAM 82, it may be necessary to terminateany processes running on subscriber station 28 which require largeamounts of RAM 82. As will be discussed below, the ability to terminatesuch processes is one of the status criteria considered before it isdecided to update subscriber station 28.

It is contemplated that a variety of techniques can be used to transferthe core firmware and auxiliary software from the update server 36 tosubscriber station 28, such as transmission of the software in packetsvia UDP/IP or TCP/IP. As the communications link 32 or the physicalmedia (wireline connection, etc.) used to transfer the software can besubject to faults or errors, the correctness of the received transfer ofthe software is verified before use. The particular method used toverify this correctness is not particularly limited and checksums, CRCs,digital signatures, etc. can be employed on all, or portions, of thetransfer, as will be apparent to those of skill in the art. If thereceived contents are not correct, and contain one or more errors, thesoftware or appropriate portions of it, can be retransmitted from theupdate server 36 to subscriber station 28 until a complete correct copyis received at subscriber station 28.

Once a complete correct copy of the update/replacement core firmware,i.e.—the “new” core firmware, is received at subscriber station 28 andstored in the RAM 82, the update process continues by writing the newcore firmware over all or part of the portion of the RSU 86 previouslyoccupied by the auxiliary software partition 112. In order to performthis overwriting, any remaining processes which were executing onsubscriber station 28 and which require read access to the auxiliarysoftware in the auxiliary software partition 112 are terminated. Oncethese processes, if any, are terminated, the new core firmware is copiedfrom RAM 82 and written to the RSU 86. The new core firmware isindicated in FIG. 4 b as a new core firmware partition 108′. As usedherein, the terms “overwriting” and “overwritten” are intended tocomprise the necessary operations for placing new data into anon-volatile memory to replace previous data and includes, in the caseof flash memory, first erasing the memory before writing new data to it,if such a step is necessary.

It is also contemplated that, to reduce the memory required in RAM 82,the updated core firmware can be written in increments as it isreceived, for example in update blocks of 256 Kbytes, provided that thereceived update can be verified as having been properly received beforewriting. In such a case, as a given amount of update data is received atsubscriber station 28, it is temporarily stored and verified in the RAM82 and then written to the RSU 86 while the next received updateoverwrites the previous received update which had been temporarilystored in the RAM 82. In this manner, various applications and processesrunning from the RAM 82 may not necessarily have to be terminated, asdiscussed below, during the update process, at least until subscriberstation 28 is rebooted.

As shown in FIG. 4 b, the overwriting is commenced at an offset from thebeginning of the auxiliary software partition 112 determined so that theend of the new core firmware partition 108′ will coincide with the endof the auxiliary software partition 112. In the example above, if theRSU 86 is 8 megabytes in total size and the core firmware partition 104is 0.25 megabytes in size, the auxiliary software partition 112 is 4megabytes in size and the core firmware partition 108 is 3.75 megabytes,so the offset at which the new core firmware partition 108′ isoverwritten onto the auxiliary software partition 112 is 4.25 megabytesfrom the start of the RSU 86, assuming the core firmware partition 104is in fact present at the beginning of the RSU 86.

After the new core firmware partition 108′ is written, its contents areverified by subscriber station 28, which reads back the contents fromthe new core firmware partition 108′ and compares them to the copy ofthe new core firmware in the RAM 82. If the new core firmware partition108′ is written in smaller portions from the RAM 82 as received, thewriting of these smaller portions is verified to that stored in the RAM82 before the next received portion overwrites the last portiontemporarily stored in the RAM 82.

In either case, if the contents read from the new core firmwarepartition 108′ cannot be verified, the writing of the new core firmwarepartition 108′, or the relevant portion of the new core firmwarepartition 108′, is performed again and the verification/rewrite processis repeated until the contents are verified.

When the contents of the new core firmware partition 108′ have beenverified as having been written correctly, the new core firmwarepartition 108′ is identified to subscriber station 28 as containing themost recent core firmware and original core firmware in the corefirmware partition 108 is then disabled from being executed bysubscriber station 28 by being marked “invalid”. In subscriber station28, wherein the core firmware partitions 108 and 108′ include a cramfsformatted Linux kernel, etc., the original core firmware in the corefirmware partition 108 is identified as invalid by overwriting thesuperblock of the core firmware partition 108 so as to alter it to nolonger be a valid superblock. Once this is done, the boot loader on thenext reboot of subscriber station 28 will only locate the superblock ofthe new core firmware partition 108′, which is the most recent validcore firmware partition, and subscriber station 28 will boot frompartition 108′.

As will be apparent from FIG. 4 b, the above results in an invalid corefirmware partition 108 and a remaining portion, if any, of the auxiliarysoftware partition 112 no longer containing useful data. Subscriberstation 28 can then write the auxiliary software from the RAM 82 (ordownload it to the RAM 82 from update server 36 if this has not yet beenperformed) to form a new auxiliary software partition 112′ in the memoryspace of the core firmware partition 108 and that remaining portion, ifany, of the auxiliary software partition 112, as shown in FIG. 4 c.Alternatively, the subscriber system 28 can be rebooted to execute thenew core firmware and the auxiliary software can then be downloaded fromthe update server and stored in the new auxiliary software partition112′. Once the writing of the new auxiliary software has been verifiedin a manner similar to that described above for the core firmware,subscriber station 28 can execute the auxiliary software (assuming ithas already rebooted and is running the new core firmware) or can berebooted to let the loader boot the updated core firmware in the newcore firmware partition 108′ and restart all services provided by boththe core firmware and the auxiliary software. In doing so, the operatingsystem will locate the superblock of the new core firmware partition108′ and, if cramfs is employed for the auxiliary software partition,the superblock of the new auxiliary software partition 112′ and form adata structure describing the repartitioned RSU 86.

As will be apparent from the above description, a valid copy of the corefirmware is always present in the RSU 86, even if subscriber station 28is turned off, looses power, requires a reboot, or is otherwiseinterrupted during the update process. In the event that the updateprocess has commenced with a new core firmware partition 108′ beingwritten over the auxiliary software partition 112 when subscriberstation 28 is turned off before the write of the new core firmwarepartition 108′ has been completed and verified, subscriber station 28will boot from the old core firmware partition 108, which is stillintact, when it is next turned on again. The absence of a validauxiliary software partition 112 will be noted and the entire updateprocess will either restart, or a transfer of valid auxiliary softwarecan be requested from the update server 36 and stored in the RSU 86 as arestored auxiliary software partition 112 and the update processdeferred until later. This latter option will be selected, for example,when the network 20 is being heavily used and the capacity to perform anupdate is not readily available.

Assuming a successful update has been performed, whenever it is desiredto again update core firmware in subscriber station 28, a new corefirmware partition 108 will overwrite a portion of the auxiliarysoftware partition 112′ and a new auxiliary software partition 112 willoverwrite the old core firmware partition 108′ and the remaining part ofthe old auxiliary software partition 112′ to again obtain theconfiguration shown in FIG. 4 a. It should be noted that it is notstrictly necessary to erase the superblock of the old core firmwarepartition 108′ after the new core firmware partition 108 is verifiedbecause, if the updating is interrupted at that stage, then when areboot occurs the boot loader will locate and use the contents of newcore firmware partition 108 before reaching old core firmware partition108′.

Each subsequent update of core firmware will result in the overwritingof the existing auxiliary software partition by the new core firmwarepartition and the overwriting of the old core firmware partition and theremaining portion of the auxiliary software partition with a newauxiliary software partition.

It should be noted that, as used herein, the term “new auxiliarysoftware” is intended to comprise both the case wherein no change hasoccurred in the auxiliary software and the new auxiliary software merelyrefers to a new copy of that unchanged software being downloaded to thesubscriber station 28 and the case wherein an updated or otherwisechanged version of the auxiliary software is downloaded to subscriberstation 28.

As shown in FIG. 5 a, if it is desired to have the location of thepartitions 108 and 112 be constant in the RSU 86 during normaloperations, the “old” core firmware partition 108 can be copied over the“old” auxiliary software partition 112 to form a copied old corefirmware partition 108″. The writing of this copied old core firmwarepartition 108″ is then verified and, once verified, the original corefirmware partition 108 is identified as invalid by overwriting itssuperblock so as to alter it or by any other suitable means. Shouldsubscriber station 28 be re-booted at this point for any reason, theboot loader will locate and use the contents of the copied core firmwarepartition 108″.

Next, the “new” core firmware is overwritten onto the original corefirmware partition 108 from the RAM 82, as shown in FIG. 5 b, andverified. The superblock of the new core firmware for original corefirmware partition 108 is not written to original core firmwarepartition 108 until the contents of the remainder of the core firmwarepartition 108 are verified, after which the superblock is written andverified. Then the copied core firmware partition 108″ is identified asinvalid by overwriting or altering its superblock or by any othersuitable means. In this manner, a reboot or other event requiringloading of the core firmware prior to verification of the write of thenew core firmware partition 108 will instead employ the copied corefirmware partition 108″.

Finally, the new auxiliary software is copied from the RAM 82 to formthe auxiliary software partition 112, as shown in FIG. 5 c and thispartition is verified before being used and subscriber station 28 isthen once again in its normal operating configuration. While thisprocess does result in the partitions 108, 112 always having the samepositions in the RSU 86, it does require additional write andverification operations to be performed to copy the contents of corefirmware partition 108 to the copied core firmware partition 108″, whichadds to the time required to perform the update and, if the RSU 86 isflash memory, may cause the RSU 86 to wear out more quickly.

In a present embodiment of the invention, updating of software in thesubscriber stations 28 is a managed process. This is especiallyimportant in a critical network or an “always on” network, such aswireless local loop providing a primary telephone line replacement FIG.6 shows the management system hierarchy of the network 20 which includesa network operations center (NOC) 200, a radio sector manager 204 foreach sector in a base station 24 in network 20 and a subscriber stationupdate client 208 for each subscriber station 28 served by the network20.

The network operations center 200 is a centrized facility operated bythe operator of the network 20 and, in addition to managing the updatingof subscriber stations throughout the network 20, can also perform othernetwork management functions such as OAM&P, etc. Radio sector managers204 are preferably located in each base station 24 of the network 20 andcan be co-located with or implemented within the update server 36. If abase station 24 is an omni-directional (single sector) base station,only a single radio sector manager 204 will be provided in that basestation 24. It is contemplated that, more commonly, a base station 24will employ non-omni-directional (beam-forming) antennas which allow itto serve increased densities of subscriber stations 28. For example, ifsixty degree beam-forming antennas are employed, a base station 24 canbe configured into six different radio sectors, each sector serving asubset of the total number of subscriber stations 28 served by that basestation 24. In such a case, six radio sector managers 204 are providedat base station 24. Finally, each subscriber station 28, as part of itscore firmware, includes an update client 208, which executes onsubscriber station 28.

In FIG. 6, the radio sector managers 204 illustrated in dashed line areintended to represent a plurality of such radio sector mangers 204 andtheir associated update clients as NOC 200 can serve several hundreds ofradio sector managers 204 and, through them, several thousand or moresubscriber stations 28 through their update clients 208.

When an update to the auxiliary software or core firmware of subscriberstations 28 has been created and the operator of network 20 wishes toimplement it, the network operations center 200 will determine thepresent version of the software loaded into each subscriber station 28being served by network 20. This determination can be performed in avariety of manners, as will be apparent to those of skill in the art. Inthe embodiment of the invention, the update client 208 of eachsubscriber station 28 reports to the radio sector manager 204 serving itthe present version of the software loaded into subscriber station 28each time the subscriber stations 28 is turned on and/or after each timean update is performed. The radio sector managers 204 forward thisinformation to the network operations center 200 where it is stored in asuitable database. As will be apparent to those of skill in the art, avariety of other techniques can be employed to determine the presentsoftware load of each subscriber station 28, including polling of theupdate clients 208 at appropriate intervals, etc.

Once the present software load of each subscriber station in network 20,or in a subset of interest of the subscriber stations 28 in network 20(for example, the network operator can be interested in only updatingthose subscriber stations 28 in a particular city), has been determined,network operations center 200 determines the subscriber stations 28 thatshould be updated. In most circumstances, it will be desired to updateall subscriber stations 28 in network 20, but it is also contemplatedthat it can be desired to update selected subsets of subscriber stations28, or even individual subscriber stations 28.

The network operations center 200 ensures that the desired updatedsoftware is available on the update server, or servers 36, which servethe radio sector managers 204 with subscriber stations 28 to be updated,transferring the updated software to the update servers 36 as necessary.Next, network operations center 200 instructs the radio section managers204 with subscriber stations 28 to be updated of the identity of thosesubscriber stations 28 and instructs them to initiate the updates.

Once a radio sector manager 204 receives update instructions from thenetwork operations center 200, it determines the activity level and orstatus of the subscriber stations 28 it manages that are to be updated.Ideally, updates are only performed when the capacity they require oncommunications link 32 is not otherwise required and/or subscriberstations 28 are not executing end user processes that will have to beinterrupted for the update process. Accordingly, radio sector manager204 first determines that it can spare and/or has capacity oncommunications link 32 to transmit the update. It is contemplated thattypically, such updates will be performed late at night or early in themorning when communications link 32 is underutilized by end users.However, it is also contemplated that an essential update, such as onerequired to stabilize operation of network 20 or to provide enhancedsecurity, etc. can be assigned an update priority by network operationscenter 200 which instructs radio sector managers 204 to perform theupdate as soon as possible, terminating or interrupting other uses ofthe capacity of communications link 32 and/or interrupting, degrading orsuspending end user activities at the subscriber stations 28 to beupdated.

Once it has been determined by radio sector manager 204 that it hascapacity on communications link 32 to transmit the update to subscriberstations 28, or in the event of a priority update that it has madecapacity, it queries the update client 208 in each of those subscriberstations 28 it is to update to determine the status of those subscriberstations 28. This status indicates the level and/or type of activitypresently taking place on that subscriber station 28.

For example, a subscriber station 28 can indicate that it has been idle(no end user activity) for ten minutes, or that it is currentlyconducting an http session for an end user, etc. As the transferreddownload of the update is typically first stored in RAM memory 82, ifthe necessary amount of memory (this amount can be a predefined amountfor all updates, or can be provided by the radio sector manager 204 inits status query to the update clients 208) selected to store thedownload is not available in RAM memory 82, subscriber station 28 willinclude this information in its status report to radio sector manager204. Alternatively, the update client 208 in subscriber station 23 candetermine if it can terminate processes and/or applications using RAMmemory 82 to free memory space and will do so, if possible, beforesending the status response to radio sector manager 204.

Radio sector manager 204 examines the status responses received fromeach subscriber station 28 to be updated and determines which subscriberstations 28 can be included in the update at this time. The updateclient 208 of each of these subscriber stations 28 then receives anupdate information transmission from radio sector manager 204 informingthe subscriber stations 28 that they are to undergo an update andindicating the channel of communications link 32 that the update is tobe transmitted on.

Radio sector manager 204 then initiates a multicast transmission of theupdate from update server 36 to the subscriber stations 28 which havebeen instructed to process the update. In the embodiment of theinvention, the update is transmitted via UDP over IP as a multicasttransmission and each transmitted packet includes a CRC checksum toverify correct receipt and a sequence number or other unique identifierof the packet so that each subscriber station 28 can determine if it hascorrectly received all necessary packets. In the event that one or morepackets have been received incorrectly or missed altogether by asubscriber station 28, such subscriber stations 28 can send a retransmitrequest to radio sector manager 204 while the transmission is inprogress and the requested packet can be retransmitted. Preferably, thisretransmission is performed over the multicast channel and is availableto all subscriber stations 28 being updated (in case more than onesubscriber station 28 requires the retransmission of the same packet)although it is also contemplated that such retransmissions can be madeto a subscriber station over a dedicated channel on communications link32 established with subscriber station 28 by radio sector manager 204for that purpose.

In the embodiment, once the entire update has been downloaded andverified, the update client in the subscriber station must determinewhen to perform the update of RSU 86. As the update will require areboot (restart) of subscriber station 28, update client 208 attempts toselect a time for the update when minimal, if any, service interruptionto the end users will occur. Again, it is contemplated that such updateswill typically be performed late at night or early in the morning or atany other time when the likelihood of end user use of subscriber station28 is low.

However, the update client 208 in a subscriber station 28 can also makean intelligent decision on when to perform the update by determiningwhat end user activities are occurring and/or the time since the lastend user activity. For example, a subscriber station 28 which last madean end user voice or data connection more than twenty minutes ago, canmake a reasonable assumption that it will be unused by an end user forthe next several minutes while the update is performed.

Again, it is also contemplated that some updates will have sufficientimportance to the operations of network 20 that they will have apriority assigned to them that enables the update client 208 toterminate end user activities on the subscriber station in order toensure the update is performed.

When the update client 208 has determined that the update can beperformed, the process discussed above is performed overwritingauxiliary software partition 112 with new firmware partition 108′, orcopied partition 108, etc.

Once a successful update has been performed and subscriber station 28has rebooted and is executing the new core firmware and/or auxiliarysoftware, an update status message is sent to radio sector manager 204informing it that the update has been completed and verifying theversion numbers of the software being executed by subscriber station 28.Radio sector manager 204 then updates its records of the subscriberstations 28 that have been updated and those that still requireupdating.

Radio sector managers 204 then repeat the process, through one or moreiterations, for the remaining subscriber stations 28 to be updated. Itis contemplated that an update will not be commenced until apre-selected proportion of the subscriber stations 28 to be updated in aradio sector are available for the update. For example, it can beselected that radio sector manager 204 will not commence the updateunless at least 50% of the subscriber stations 28 to be updated in itssector are available for updating. If this threshold is not reached, theupdate will be delayed until the threshold can be met or until thenetwork operations center lowers the threshold (eg. to 35%) or raisesthe priority of the update so that subscriber stations 28 are forced toimplement the update.

Network operations center 200 is advised of the status of the update bythe radio sector managers 204. Thus, network operations center 200 candetermine the number of subscriber stations 28 that have been updatedand the number that remain to be updated. If network operations center200 observes that the update is being performed for fewer subscriberstations 28 than it desires, it can apply priority to the update toforce subscriber stations 28 to ready themselves for the update, etc.

While it is contemplated that in most circumstances the core firmwareand auxiliary software updates will be transmitted as one update, it isalso contemplated that in some circumstances it may be desired totransmit the core firmware update first and, after the subscriberstations 28 have successfully installed that update, the auxiliarysoftware update will be transmitted. It is also contemplated that insome circumstances it will be desirable to only update the auxiliarysoftware. In such a case, the core firmware is not updated and theupdated auxiliary software is written over the existing auxiliarysoftware partition 112.

FIG. 7 shows a flowchart of the update process described above. When thenetwork operations center 200 wishes to update devices in network 20, atstep 300 the devices that require the update to be installed aredetermined. At step 304 the update is transferred or otherwise madeavailable to the update server 36, or servers, from which the updatewill be transferred to the devices to be updated.

At step 308, each radio sector manager 204 determines which of thedevices it serves are available for updating. At step 312, the radiosector manager 204 instructs those devices that they will be updated andprovides the details of the update communication, such as the multicastparameters, etc.

At step 316, the update is transmitted to the devices being updated.Each intended device verifies the reception of the transmitted update,either when the transmission is completed or as the transmission isoccurring, and at step 320, devices which have received a portion of thetransmission which is in error or have missed reception of a portion ofthe transmission advise the radio sector manager 204 of this fact andthe radio sector manager 204 which will cause those portions to beretransmitted.

At step 324, once the devices have a correct copy of the update, thedevices determine the appropriate time to perform the update. Asmentioned above, this determination can be trivial (i.e. —perform theupdate regardless of the status of the device) or can be made dependingupon the status of the device, including factors such as currentprocesses executing on the device, the time since an end user processwas executed, etc.

When the update and rebooting of the device is achieved, at step 328 thedevice will notify the radio sector manager 204 managing it that it hasbeen updated and can provide the details of its present software load.

At step 332, each radio sector manager 204 determines if any devices itmanages remain to be updated. If such devices do remain, steps 308through 328 are performed again, as necessary. If no such devicesremain, the update process completes at step 336.

While the embodiments discussed herein are directed specificimplementations of the invention, it will be understood thatcombinations, sub-sets and variations of the embodiments are within thescope of the invention.

The above-described embodiments of the invention are intended to beexamples of the present invention and alterations and modifications maybe effected thereto, by those of skill in the art, without departingfrom the scope of the invention, which is defined solely by the claimsappended hereto.

1. A method of updating software in a plurality of remote devices eachof which has insufficient non-volatile rewritable storage capacity tostore both an updated and a previous version of the software and each ofwhich is connected to a network, comprising the steps of: (i) placingthe update onto an update server, the update comprising at least a corefirmware update; (ii) identifying the devices connected to the networkto be updated; (iii) transferring the update from the update server tothe identified devices through the network, each identified deviceverifying the reception of the update, requesting retransmission of andreceiving any previously incorrectly received portion of the update;(iv) writing the core firmware portion of the received update into anon-volatile rewritable storage unit so as not to overwrite the previousversion of the core firmware that is present in the storage unit; (v)verifying the core firmware portion of the received update written intothe storage unit; (vi) identifying the verified updated core firmware asbeing the valid core firmware to be used by the device and identifyingthe previous version of the core firmware as being unusable; and (vii)rebooting the device to load and execute the updated software.
 2. Themethod of claim 1 wherein, between steps (iii) and (iv), the previousversion of the core firmware is copied over auxiliary software stored inthe storage unit and verified, the copy identified as the valid corefirmware to be used by the device and the original identified as beingunusable.
 3. The method of claim 2 wherein the update further includesupdated auxiliary software and the auxiliary software is received andverified by the device and wherein, between steps (vi) and (vii), theunusable previous version of the core firmware is overwritten with theauxiliary software update.
 4. The method of claim 1 wherein the updatefurther includes updated auxiliary software and the auxiliary softwareis received and verified by the device and wherein, between steps (vi)and (vii), the unusable previous version of the core firmware isoverwritten with the auxiliary software update.
 5. The method of claim1, wherein step (ii) also comprises the device informing the networkwhether or not it is available to be updated.
 6. A system for remotelyupdating core firmware in at least one electronic device across acommunications link, the system comprising a memory sub-system withinthe at least one electronic device including: non-volatile rewritablememory in which the core firmware is stored and which is sufficientlylarge to store auxiliary software but not large enough to simultaneouslystore the core firmware, an updated version of the core firmware, andthe auxiliary software, the core firmware including instructions forwriting an updated version of the core firmware into the non-volatilerewritable memory so as not to overwrite the previous version of thecore firmware, and then disabling the previous version of the corefirmware such that on rebooting of the at least one electronic devicethe updated version of the core firmware will be loaded and executed;and an update server, operable to transfer an update to the at least oneelectronic device across the communications link, the update comprisingthe updated version of the core firmware.
 7. The system of claim 6,wherein the core firmware includes instructions for writing an updatedversion of the auxiliary software into the non-volatile rewritablememory so as to overwrite at least a portion of the disabled previousversion of the core firmware, but not to overwrite the updated versionof the core firmware.
 8. The system of claim 7, wherein the memorysub-system additionally comprises: non-volatile memory includinginstructions that are executed when the electronic device reboots andcause the non-volatile rewritable memory to be scanned for a version ofthe core firmware that is not disabled and that version of the corefirmware to be loaded and executed.
 9. (Cancelled)
 10. (Cancelled) 11.(Cancelled)
 12. The system as claimed in claim 6, wherein writes to thenon-volatile rewritable memory are verified.
 13. The system as claimedin claim 12 wherein the update client is further operable to inform theupdate server as to whether the at least one electronic device isavailable for updating at a given time, the update server beingresponsive to the information received from the update client to delayupdates to the electronic device when the electronic device is notavailable for updating.
 14. The system as claimed in claim 13 whereinthe update server can prioritize an update such that the update clientwill make the electronic device available for the update that wouldotherwise be unavailable.
 15. A memory sub-system for use in anelectronic device, comprising: non-volatile rewritable memory in whichcore firmware and auxiliary software are stored, the core firmwareincluding instructions for writing an updated version of the corefirmware into the non-volatile rewritable memory so as to overwrite atleast a portion of the auxiliary software, but not to overwrite theprevious version of the core firmware, verifying the updated version ofthe core firmware, and disabling the previous version of the corefirmware such that on rebooting of the electronic device the updatedversion of the core firmware will be loaded and executed. 16.(Cancelled)
 17. The memory sub-system of claim 15, wherein the corefirmware includes instructions for writing an updated version of theauxiliary software into the non-volatile rewritable memory so as tooverwrite at least a portion of the disabled previous version of thecore firmware, but not to overwrite the updated version of the corefirmware.
 18. The memory sub-system of claim 17, additionallycomprising: non-volatile memory including instructions that are executedwhen the electronic device reboots and cause the non-volatile rewritablememory to be scanned for a version of the core firmware that is notdisabled and the version of the core firmware that is not disabled to beloaded and executed.
 19. (Cancelled)
 20. (Cancelled)
 21. (Cancelled) 22.A method of updating core firmware stored in non-volatile rewritablememory of an electronic device together with auxiliary software with anupdated version of the core firmware, comprising the steps of: (i)writing the updated version of the core firmware into the non-volatilerewritable memory so as to overwrite at least a portion of the auxiliarysoftware, but not to overwrite the previous version of the corefirmware; and (ii) disabling the previous version of the core firmwaresuch that on rebooting of the electronic device the updated version ofthe core firmware will be loaded and executed.
 23. (Cancelled)
 24. Themethod of claim 22, wherein when the electronic device is rebooted, thenon-volatile rewritable memory is scanned for a version of the corefirmware that is not disabled and that version of the core firmware isthen loaded and executed.
 25. (Cancelled)
 26. A system for remotelyupdating at least one electronic device across a communications link,where said system comprises: an update server, operable to transfer anupdate to the at least one electronic device across the communicationslink, the update comprising core firmware and auxiliary software; avolatile memory to temporarily store the transfer received from theupdate server; a non-volatile re-writable storage unit within said atleast one electronic device divided into at least first and secondpartitions, the first partition storing one of a version of corefirmware and auxiliary software and the second of the partitions storingthe other of a version of core firmware and auxiliary software; and anupdate client executing on the device and operable: (i) to overwrite theversion of the auxiliary software stored in one of the first and secondpartitions with the received updated core firmware stored in thevolatile memory and to verify the success of this write; (ii) toconfigure the device to execute the core firmware stored in (i) upon thenext reboot of the device; (iii) to overwrite the version of the corefirmware stored in the other of the first and second partition with thereceived updated auxiliary software store in the volatile memory and toverify the success of this write; and (iv) to reboot the device toexecute the updated core firmware and updated auxiliary software. 27.The system as claimed in claim 26 wherein said update client is furtheroperable to inform the update server as to whether the device isavailable for updating at a given time, the update server beingresponsive to the information received from the update server to delayupdates to the device when the device is not available for updating. 28.The system as claimed in claim 27 wherein the update server canprioritize an update such that the update client will make a deviceavailable for the update that would otherwise be unavailable.